In most digital control computer systems, the gathering and distributing of data is a necessary activity that must be performed during each phase of computations. This activity is usually delegated and controlled by an Input Output Controller (IOC). The IOC function contributes significantly to the system's overhead since its associated hardware and/or software elements diminish the overall performance and other capabilities of the system available for performing the primary control computer functions. The performance and other operational requirements of IOCs are usually quite demanding and vary widely from application to application. Consequently, there is a critical need in most digital control computer systems for a generic, efficient and flexible IOC that can meet the demanding and varying requirements of multiple applications with a low overhead.
The implementation of an IOC function may take on many forms. For example, an IOC might be constructed as a rather inflexible state machine microprogrammed in PROM and designed to perform the gathering of inputs and distribution of outputs in a predefined and repetitive manner. Such a state machine could then be specifically tailored, i.e., microprogrammed, to a particular mode of operation of the control computer system.
The resulting IOC, which would be simple to design, will operate in a predictable manner and meet the needs of most single mode operations. However, such an IOC would not meet the flexibility needs of a multimode control computer system in which the data elements and the gathering and distribution process itself must change either statically or dynamically. Hence, there is a need for more flexible input/output controllers which can retain some of the simplicity of the state machine approach.
At the other extreme, an IOC function might be implemented entirely in software, in an embedded software programmable microprocessor. However, it might be noted that the basic tasks of an IOC, namely, the movement of data between a set of sources and destinations and the control of I/O devices do not demand the complexities and complete flexibilities offered by a micro-processor in such a completely software based approach. Furthermore, the arithmetic and data manipulation capabilities of a microprocessor are not essential for the data transfer operation of an IOC. Thus, such a microprocessor-based IOC software tends to under utilize the microprocessor and, for this reason, the microprocessor in such an IOC usually ends up performing some of the primary control computing functions which, in turn, can tend to interfere with the IOC's primary I/O control capabilities.
The debate over which approach is better has been going on for some time and is not expected to be resolved here.
However, in many applications requiring extremely rapid control of devices, a microprocessor based approach is unsuitable. Some of the other difficulties associated with a microprocessor based IOC approach in this context are: (i) the need for design and verification of complex, high performance software, such as required by a real time system, (ii) the lack of autonomous, repeatable operations, and (iii) the usually larger failure rates of the associated hardware.
A state machine sequencer based IOC, on the other hand, can be easily microprogrammed in PROM and verified to perform a given set of data transfer and device control operations autonomously. However, as mentioned above, a state machine IOC is very inflexible and may not be cost effective in terms of hardware, particularly if it is designed using off-the-shelf I/O controller components.
In many systems, the IOC's are required to manage a special type of interface, namely, digital links. The management of these data links between many subsystems involves special capabilities unlike those required for managing localized analog or discrete signals and interfaces.
In a redundant control computer system, for example, a common task performed by an IOC involves the transfer of data over a serial data link to and from a set of redundant channels and (sub)systems which may or may not be computational frame or task synchronized ("redundant channels" means plural subsystems having the same hardware). These transfers are required to be error free. The transfers are required to occur at certain specific times depending on events and usually involve a large number of input and output signals such as voting plane signals and signals indicative of intermediate results of computations.
An IOC, unlike a control processor, is not required to perform any sophisticated handling of data, in terms of command response protocol, data redundancy or consistency. What is required, in the context of redundant data links, is an autonomous internal bus between the IOC and a local processor's memory involving no control processor overhead in the transmission and reception of data to and from other channels and systems which may or may not be synchronized. Such a link interface IOC cannot be used for managing sophisticated data buses such as the MIL-STD-1553, LAN, etc., because they are always asynchronous and require sophisticated protocol and data consistency management which are best performed by a dedicated bus controller function embedded in a processor. Such sophisticated links also involve considerable hardware overhead.
The gathering and distribution of data by any IOC requires access to memory which is also being used by the control processor. This is most commonly done in a direct memory access (DMA) mode where the processor is requested access to the data/address buses and the data is transferred on receipt of a bus grant signal. During this transfer interval, the processor is essentially idle. This loss of real time by the processor linearly increases with the number of data transfers by the IOC, to a point where it can significantly affect the overall throughput capability of the host processor. Another difficulty with this DMA approach is that the bus grant signal is essentially asynchronous and may take more or less time depending upon the processor and its current activity. If the bus grant signal is held off for a long time, it can lead to loss of rapidly arriving internal bus messages, particularly if they are asynchronous in nature. A common solution to this problem is to buffer the incoming bus data. However, this approach has a significant hardware penalty and can only provide limited relief. Another, new approach, disclosed herein, involves the use of dual port RAMs which can internally arbitrate between two asynchronous data buses for memory accesses. However, this also has a significant hardware penalty and, though it fulfills the need for an autonomous bus between the IOC and the control processor's memory, it is not always affordable.
In summary, there is a need for an Input/Output Controller function by which data may be gathered and distributed and by which input/output devices including data links, synchronous or asynchronous in nature, are controlled in a flexible, autonomous and predictable manner without real time penalty to the host control computer in the channel.